home *** CD-ROM | disk | FTP | other *** search
-
- 05/22/94
-
- Added support for Fossil Drivers.
-
- To use a Fossil Driver as the communications interface, place
- the word FOSSIL on the 5th line of the Door Configuration
- File. GAPCDR has been tested and confirmed to work with
- BNU and X00.
-
- Note that due to the limitations of the Fossil's Interrupt 14
- interface, the highest baud rate that can be set is 38400 bps.
- It is possible to configure the Fossil Driver to lock the
- baud rate (BNU supports up to 38400 bps and X00 supports up to
- 115200 bps). When the port is locked, the Fossil Drivers are
- supposed to ignore any requests for a change in port speed (we
- have not confirmed if they actually do this). However, the
- GAPCDR Communications routines will reject any baud rate higher
- than 38400 bps and will return an error if you attempt to
- initialize the port at a higher speed. The BBS software must be
- configured for a port speed no higher than 38400 bps.
-
- Made library compatible with Borland C version 4.x. This release
- of GAPCDR works only with Microsoft C version 7 or greater and
- Borland C version 4 or greater.
-
- It is no longer necessary to specify which compiler you are
- using in the COMPILER.H file. If you are using Microsoft C
- you are not required to include this file in your source files.
- However, if you are using Borland C, you must include this file
- because the Borland compiler still does not support single (or
- double) underscores on all non-ANSI functions (it uses it on
- some non-ANSI functions but not all of them).
-
- The structure packing pragma was moved out of the source files
- and placed in the GAPSTRUC.H include file where it belongs. Don't
- remove or change the position of the packing pragmas or your
- programs will not be able to read or write the BBS specific files.
-
-
- 02/17/94
-
- Added support for C++ compilation. A couple of C++ reserved words
- were removed from the structures and all of the GAPCDR header modules
- were given "C" linkage.
-
- This "C" linkage consists of the following:
-
- #ifdef __cplusplus
- extern "C" {
- #endif
-
- .... GAPCDR variables and declarations here
-
- #ifdef __cplusplus
- }
- #endif
-
- If your compiler requires a different form of informing it that
- the source file is a "C" file and not a C++ file, you will need
- to change the "extern "C" {" at the beginning of the include
- files and the "}" at the end of the include files to whatever form
- your compiler requires. In addition, if your compiler does not
- define __cplusplus when it is building a C++ program, you will need
- to change the ifdef's in the header files as well.
-
- The above defines and extern "C" declaration work for Microsoft C.
-
- If you need to change the C Linkage declarations, the two header files
- that you will need to modify are GAPCDR.H and GAPSTRUC.H (at the
- beginning and end of the files).
-
-
- 09/13/93
-
- RIP support has been added.
-
- To check if a caller has RIP capability, call the function
- 'check_rip' immediately after calling 'init_door'. This function
- will send the RIP interrogation sequence and wait for a response
- from the remote terminal. If the remote terminal supports RIP,
- the flag 'hasrip' will be set to 1. The 'show_file' function
- uses this flag to determine whether or not to send a RIP file
- to the remote terminal instead of the regular ASCII/ANSI file.
-
- RIP files are named the same as your ASCII/ANSI files except
- that they have an 'R' appended to the base part of the name:
-
- MAINM MAINM.50 NEWS NEWS1 WELC WELC1
- MAINMG MAINMG.50 NEWSG NEWS1G WELCG WELC1G
- MAINMR MAINMR.50 NEWSR NEWS1R WELCR WELC1R <- RIP
-
-
- Note that 'check_rip' will wait up to 4 seconds for a response
- from the remote terminal. If the caller has RIP capability, the
- delay will probably not be noticeable. If the caller does NOT
- have RIP capability, the 4 second delay will be noticeable. If
- the caller does not have color enabled, then there is no need
- to check for RIP capability (GAP BBS's, other BBS software may
- be different).
-
- Example:
-
- doorcnf = read_cnf("DOOR.CNF");
- init_door();
- fclose(doorcnf);
-
- if (color && !local) ! if not local and has color
- check_rip(); ! see if can handle RIP
-
- // if RIP capable, hasrip = 1
-
- If the caller does have RIP capability, an 'R' will be displayed
- on the Status Line.
-
-
- 04/16/93
-
- GAPCDR now supports the DigiBoard COM/Xi series of Intelligent
- Serial Communications boards. These boards contain 4 or 8 serial
- ports along with their own on-board processor to control the ports.
- These boards are actually a single-board computer dedicated to handling
- serial port I/O.
-
- By moving the serial I/O functions from the Host Computer to the
- DigiBoard, the IRQ and Interrupt Latency bottleneck that plagues
- Multi-Tasking users is eliminated.
-
- GAPCDR supports the DigiBoard in two ways:
-
- Direct Programming and INT14/EBIOS calls.
-
- Direct Programming is the fastest because it eliminates the need
- for costly software interrupt calls to a slower BIOS. In addition
- it does not require the presence of a Device Driver which basically
- performs the same functions as the Direct Programming method.
-
- INT14/EBIOS requires that a Device Driver be loaded (this driver
- is supplied by DigiBoard). Serial Port I/O is performed by issuing
- software interrupts (Interrupt 14).
-
- Whether or not to use the Direct Interface or the INT14/EBIOS
- Interface depends on the BBS which will be running the GAPCDR
- program. If the BBS is utilizing the Device Driver, then that is
- how a GAPCDR program must be configured. If the BBS is a GAP system
- and the Sysop is using the Direct Interface, then the GAPCDR program
- must be configred the same.
-
- The two interfaces can not be intermixed since the Direct Interface will
- essentially put the Device Driver to sleep.
-
- When using the INT14/EBIOS interface and the DigiBoard supplied Device
- Driver, it is not necessary to turn on the "Character Waiting" flags
- for each of the ports. GAPCDR does not use these flags as they basically
- defeat the purpose of using a multi-port board in a multi-tasking
- system. To use these flags an IRQ must be dedicated to the DigiBoard.
- If the flags are not used, the IRQ need not be set.
-
- Imagine running 8 ports under a Multi-Tasker where all 8 ports
- are in use. As characters are received by each of the 8 ports, an
- interrupt is generated. The Device Driver must service the
- interrupt request and since the driver runs on the Host Computer,
- it will be spending a lot of precious time figuring out which of
- the ports generated the interrupt and updating its "Character
- Waiting" flag for that port.
-
- By disabling the "Character Waiting" flags and not utilizing the
- IRQ, the Host Computer will not know it has 8 serial ports running
- at high speed at the same time.
-
- If, however, the Sysop has the IRQ and Character Waiting flags enabled,
- no harm is done. GAPCDR simply will not utilize the flags.
-
- The Character Waiting flags are provided because making Interrupt
- 14 calls takes longer than simply checking a memory address (which,
- by the way, is what the Direct Programming interface does).
-
- To use a DigiBoard with a GAPCDR program, 4 additional lines have been
- added to the Door Configuration file. These 4 new options are:
-
- Line 5 - The COM Port Interface to use:
-
- STANDARD = Regular Communications Port Interface. This
- is what you would normally use.
-
- DIGIBOARD = Direct DigiBoard Programming Interface. Must
- be used in conjunction with a program called
- RESETDIG.EXE. If you don't have this program
- but have a DigiBoard, then use the following
- option.
-
- INT14/EBIOS = Indirect DigiBoard Support via a Device Driver.
- All Communications to the DigiBoard (or any
- board that supports INT14/EBIOS) are performed
- via a Software Interrupt that the Device Driver
- handles.
-
- Line 6 - This is the DigiBoard Memory Window, or the address the
- card uses as a communications area between the card and
- the Host Computer. Only needed if using an Interface set
- to DIGIBOARD. If using STANDARD or INT14/EBIOS, this can
- be set to 0. This address must be entered in Hexadecimal.
-
- Valid entries are: C000, C800, D000, and D800
-
- Line 7 - This is the DigiBoard I/O Port address that the Board is
- attached to. Only needed if using an Interface set to
- DIGIBOARD. If using STANDARD or INT14/EBIOS, can be set
- to 0. This address must be entered in Hexadecimal.
-
- Valid entries are: 100, 110, 120, 200, 220, 300 and 320
-
- Line 8 - This is the DigiBoard Channel Number for the port this
- program will be utilizing. This is REQUIRED for DIGIBOARD
- and INT14/EBIOS Interfaces. This is 1 - 8 for the
- DIGIBOARD Interface and usually 4 - 11 for the INT14/EBIOS
- Interface. This number tells the program which of the
- Com Ports on the DigiBoard it should use.
-
-
- The new configuration file for a GAPCDR that will be using a DigiBoard
- Serial port would look like the following:
-
- DOOR.CNF
- ----------------------
- C:\GAP
- The Crow's Nest BBS
- 4
- 03F8
- INT14/EBIOS
- D000
- 320
- 4
-
- Lines 3 and 4 are ignored by the program and can be set to 0.
- Because this is an INT14/EBIOS interface, lines 6 and 7 are also
- ignored. Line 8 is the Channel Number and in this case, it is the
- first serial port on the DigiBoard (Channel Numbers 1 - 4 are
- generally reserved for COM 1 - COM 4 on the Host Computer, although
- this is up to the Sysop and how he/she configured the Device Driver).
-
-
- To use the Direct Programming Interface, the configuration file
- would look something like:
-
- DOOR.CNF
- ----------------------
- C:\GAP
- The Crow's Nest BBS
- 4
- 03F8
- DIGIBOARD
- D000
- 320
- 1
-
- Lines 3 and 4 are ignored by the program and can be set to 0.
- Line 6 is the Memory Window that the DigiBoard and the program
- use to communicate with each other. Line 7 is the I/O port that
- the board uses. Line 8 is the Channel Number which, in this case,
- is the first serial port on the DigiBoard.
-
-
- To use the Standard Com Port Interface, the configuration file
- would look something like:
-
- DOOR.CNF
- ----------------------
- C:\GAP
- The Crow's Nest BBS
- 4
- 03F8
- STANDARD
- 0
- 0
- 0
-
- Lines 3 and 4 are used ONLY if the program will be using a COM port
- other than COM 1 or COM 2. They can be set to 0 if the program will
- not be using non-standard COM ports. Line 5 tells the program to
- use its own internal interrupt handler. Lines 6-8 are not used and
- can be set to 0.
-
- Note that even if the DigiBoard specific options are not used or needed
- they must still be present in the Configration File and all Door Specific
- options now begin on Line 9.
-
-
- 02/18/92
-
- GAPCDR is now compatible with GAPBBS version 6.
-
-
- 01/12/91
-
- Since the new MASM 6 does not like the word WAIT to be used as
- a procedure name, the function wait() has been changed to timer().
-
- If you are converting from a previous version of GAPCDR, please
- note that line 3 of the Door Configuration File (the one that was
- either a 0 for GAP or a 1 for PCB, has been removed. GAPCDR no
- longer cares what BBS system it is operating under.
-
- The CNF file now has just 4 required lines. Please consult
- the documentation for the proper format of the Door Configuration
- File.
-
- The show_file function no longer supports the old GAP AnsiCmds
- to clear the screen and disable the More prompt.
-
- Future releases of GAPCDR will include support for the full
- replaceable parameter command set of GAP and PCB.
-
- GAPCDR now writes directly to the screen (and is fully DESQview
- compatible). It contains its own built in ANSI driver. Because
- of the built in ANSI driver, if you used one of the C console
- output statements (printf, cputs, etc), you need to change
- those statments to use the GAPCDR functions of lputs or lputc.
-
- If you use C's console output statments to write to the local
- screen, your local screen will be quite a mess!
-
- All of the GAPCDR functions are now documented. A printed and
- bound manual is also available. Many new functions were added
- and they are all explained in the manual.
-
-